Companies are rapidly adding dynamic, rich and interactive capabilities to improve user experiences, grow online audiences, and drive page views and transactions. As Web sites evolve toward completely rich, dynamic online channel experiences, businesses face a new, but stark challenge. Today's consumers have come to expect highly interactive online experiences. When e.g. watching a movie, they demand a smooth, flawless experience. In the International Application WO2010/005349 is disclosed a method for an IPTV Set Top Box to access content from an external domain outside the IPTV service provider's domain by retrieving and converting required content from the external domain into a format that is accessible via the IPTV Set Top Box.
P2P streaming applications work in much the same way as other P2P file share clients except that instead of downloading files, the users download streams. These streams are then exchanged in real-time with other users.
FIG. 1 discloses Peer2View (P2View) which is a Peer-to-Peer live streaming application. FIG. 1 shows an Internet network 12 comprising P2View peers 13-15. The figure also discloses an origin server 10, a Content Distribution Network CDN 11 and a P2P client 16. The figure shows delivering of HTTP streams made out of HTTP chunks 1-6. The chunks are delivered either from the origin server or a server in the content distribution network CDN i.e. the file that is to be streamed has been broken up in chunks and is streamed from either the origin, server or a server in the CDN network. In case many clients simultaneously ask for streams from a server it may result in system overload. Due to this, instead of having one server (origin or CDN) the server has been broken down into smaller peers (Peer2View peers in the Internet) and the chunks are now also part of every peer 13-15. When the P2P client 16 is looking for e.g. chunk 4 it will make a decision which chunk source is the closest or shortest in terms of delay, and fetch chunk 4 from there. An example of the basic principle is as follows. When the P2P client 16 enters the system, the client starts to ask for existing, video, stream channels. The client hereby contacts a channel list server (not in figure) and the server returns back a list of channels. The client makes a selection of a desired channel and contacts a tracker (not in figure) in the Internet network. The tracker knows of all the peers 13-15 already receiving the channel of interest. The tracker also has knowledge of the CDN server 11 and the origin server 10. The P2P client performs measurements e.g. by using a BART method for available bandwidth estimation, between all replied peers to see which peer is the most appropriate to ask for a needed chunk and then makes a chunk request.
Problems exist with the above described technique. A first problem is that the P2P stream generates a lot of traffic. According to P2P principles, if a chunk is received, the recipient of the chunk has to share a chunk back. The problem with P2P is that when there is an “unlimited” amount of peers receiving and sharing, it will be difficult for the operator to dimension, network capacity. A second problem is that the impact of this big amount of traffic on the network creates contention for best effort traffic class. A third problem is extra costs such as increased costs for mobile access (air-interface), transport cost in aggregation and backbone network, and increased cost for Internet peering.